Skip to content

Conversation

@jona159
Copy link
Contributor

@jona159 jona159 commented Sep 25, 2025

No description provided.

@mashazyu
Copy link
Contributor

@jona159 , per our conversation I am adding summary of our discussion.

I tested data upload presented in this PR via senseBox:bike app.

  1. First, I got the following error message:

error 422: {"code":"UnprocessableEntity","message":"Cannot read properties of undefined (reading 'decodeMessage')"}

Cursor suggested the following fix, that worked for me locally

Issue:

Measurement upload failing with: "Cannot read properties of undefined (reading 'decodeMessage')"

Root Cause:

The decoder lookup was failing when content-type included charset (e.g., "application/json; charset=utf-8")

Fix:

Modified one file: app/lib/decoding-service.server.ts

Added a normalization function and updated the decoder lookup:

// NEW: Normalize content type to match decoder keys

function normalizeContentType(contentType: string): string {

  const normalized \= contentType.toLowerCase().split(';')[0].trim();

  if (normalized.includes('json')) return 'application/json';

  if (normalized.includes('csv')) return 'text/csv';

  if (normalized \=== 'application/sbx-bytes-ts') return 'application/sbx-bytes-ts';

  if (normalized \=== 'application/sbx-bytes') return 'application/sbx-bytes';

  return normalized;

}

// UPDATED: Use normalized content-type for decoder lookup

export async function decodeMeasurements(

  measurements: any,

  options: { contentType: string; sensors: any[] }

): Promise<any[]> {

  try {

const normalizedContentType \= normalizeContentType(options.contentType); // ADDED

const handler \= decodeHandlers\[normalizedContentType\]; // CHANGED

if (!handler) { // ADDED null check

  throw new Error(\`No decoder found for content-type: ${options.contentType}\`);

}

return handler.decodeMessage(measurements, { sensors: options.sensors });
  } catch (err: any) {

const error \= new Error(err.message);

error.name \= "ModelError";

(error as any).type \= "UnprocessableEntityError";

throw error;
  }
}
  1. After applying the fix I was able to "bulk upload" track data from app. I verified that data stored in local database matched track data stored in the app. In other words, I believe data is stored correctly.

Please let me know, if any furhter testing is needed.

@jona159 jona159 marked this pull request as ready for review October 15, 2025 07:29
@jona159 jona159 linked an issue Oct 15, 2025 that may be closed by this pull request
Copy link
Collaborator

@scheidtdav scheidtdav left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do get the reason why you chose to do it, but I would prefer sticking to the convention of naming our api tests the same as the route.

Aka if we test api.boxes.$deviceId.$sensorId.ts the test should be named api.boxes.$deviceId.$sensorId.spec.ts.
This keeps the files a little shorter and separates the concerns nicely, letting everyone involved find what they search for (hopefully). Approach-wise this is probably considered more of an integration than a unit test.
If you want to add unit tests, I 'd say we move it out of the routes/ folder.
Does that make sense?

@scheidtdav scheidtdav merged commit 70ee815 into dev Oct 22, 2025
6 checks passed
@scheidtdav scheidtdav deleted the feat/postNewMeasurements branch October 22, 2025 08:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

migrate /boxes/:boxId/data & /boxes/:boxId/:sensorId

3 participants